Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-147

Text File | 1996-05-18 | 84KB | 2,288 lines

C.S.M.P. Digest             Sat, 18 May 96       Volume 3 : Issue 147

Today's Topics:

        CGrafPort vs GWorld
        DSp Gamma Fading (was Re: PageFlipping on 68K)
        Full Screen Scrolling
        Getting Partition Info (as opposed to volume...)
        Getting monitor's scan rate?
        Is there a "bad" fileRefNum value?
        Mac Tutorials Here!
        Overlaying a PICT onto a background
        Preventing Aliases from being automatically resolved?
        Restricting PBCatSearch to a single directory
        SetApplLimit
        Time running out in year 2040
        To sync to VBL or not to sync....
        [Q] Clean way to know when a serial port is "stolen"



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet
newsgroups comp.sys.mac.programmer.help, csmp.tools, csmp.misc and
csmp.games. It is designed for people who read news semi-regularly and
want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it. Ask your systems
administrator(s) for details. If you don't have access to news, you
may still be able to post messages to the group by using a mail server
like anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is ftp://ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From Andrew Edward White <andreww>
Subject: CGrafPort vs GWorld
Date: 2 May 1996 04:02:17 GMT
Organization: School of CompSci & Eng, Uni Of NSW, Oz


If all I want to do is simple blitting between off screen ports and a
window (no fades, no palette animation, etc), is it better to use a GWorld
or a CGrafPort?  And Why?

(Basically, is the extra memory overhead for a GWorld worth it, either in
terms of speed or ease of coding?)

--
Andrew White
[e-mail]
URL: http://www.cse.unsw.edu.au/~andreww/
"A complex problem is merely a simple hierarchy of simple problems"


+++++++++++++++++++++++++++

>From Andrew Barry <[e-mail]>
Date: Thu, 02 May 1996 16:11:19 +1100
Organization: Connect.com.au P/L, Sydney, Australia

> If all I want to do is simple blitting between off screen ports and a
> window (no fades, no palette animation, etc), is it better to use a GWorld
> or a CGrafPort?  And Why?
>
> (Basically, is the extra memory overhead for a GWorld worth it, either in
> terms of speed or ease of coding?)

I'd say yes.

(a) Your code will be more compatible:
  - it's a bit messy putting a CGrafPort together, and this won't
    be allowed under Copland and later (though you could possibly
    do it through accessor functions)
  - if the screen colours/depth gets changed on you, then your stuff
    will still display properly - instead of displaying crap.
    (though you will take a speed hit).
(b) Your code could be faster:
  - accelerated video cards can have GWorld memory - which means
    that blitting from the GWorld to the screen can be faster,
    as well as the accelerator being able to operate on the
    offscreen buffer - though it's difficult to quantify the
    speedup - particularly if you directly manipulate the pixels
    yourself, since they will be slower. Take note of the flag to
    force the GWorld to be in local memory (useLocalMem?).

Andrew Barry

+++++++++++++++++++++++++++

>From [e-mail] (Christopher L Tate)
Date: Thu, 2 May 1996 13:49:09 GMT
Organization: The World Public Access UNIX, Brookline, MA

Andrew Edward White (andreww) wrote:

: If all I want to do is simple blitting between off screen ports and a
: window (no fades, no palette animation, etc), is it better to use a GWorld
: or a CGrafPort?  And Why?

: (Basically, is the extra memory overhead for a GWorld worth it, either in
: terms of speed or ease of coding?)

There is almost never a good reason to roll your own offscreen graphics
contexts instead of using GWorlds, IMHO.  The GWorld package supports a
whole lot of bells and whistles (such as ensuring proper alignment with
a monitor's pixel map, and support for accelerated video cards) that are
big performance wins, and which can be a whole lot of hassle to get to
work right on your own.

If you need special manipulation, e.g. for specialized applications such
as games, then you might consider handling the pixel data yourself.  But
it's a *lot* more work than using GWorlds, and most applications don't
need that litte bit of extra performance.

--
Christopher Tate <*> [e-mail] <*> http://world.std.com/~ctate/
                  "What's in the briefcase?"   "Kosh."

---------------------------

>From [e-mail] (Cary Farrier)
Subject: DSp Gamma Fading (was Re: PageFlipping on 68K)
Date: Sun, 05 May 1996 09:49:38 -0700
Organization: Apple Computer, Inc.

In article <[e-mail]>, Dave Howell > That's great; I
didn't know that. Is there some documentation about that
> or some way to tell which have that capability and which don't? Can you
> post a list?

I'll start working on a list.

> Cary, on another note, will DrawSprocket support gamma fading in a nice
> high-level way so that third-party developers no longer have to make
> direct video driver calls?

You bet, it's already there.  There are three calls:

DSpContext_FadeGammaOut()

   Auto-fades the gamma to zero intensity over 1 second.  The user can
   abort the fade with a key press or mouse button.

DSpContext_FadeGammaIn()

   Reverse of FadeGammaOut()

DSpContext_FadeGamma()

   Allows you to manually set the current intensity level (with respect
   to normal), so you can manually fade the gamma in your own fashion.

All of the calls can work on a single monitor, or on all monitors
simultaneously.

All of the calls allow you to specify a non-black RGBColor as the
"zero intensity" color, so instead of fading to black you can fade to
white (or any other color).

In the manual fade:

If you specify an RGBColor to fade to, then you can specify intensity
levels < 0 && > -100 to fade to black from the RGBColor, so you can
fade to red from your game, then from red to black.

You can also set the gamma to > 100%, and the colors will converge
on white (sorta an "overdrive").

-> Cary

--
- -------------------------------------------------------------------
Cary Farrier, aka Mr. DrawSprocket
Software Engineer, Apple Game Technology Group
[e-mail]


---------------------------

>From [e-mail]
Subject: Full Screen Scrolling
Date: 17 Apr 1996 19:55:31 GMT
Organization: Interport Communications Corp.

Okay here goes...
   How difficult would it be to write an arcade style game that uses full
screen, 640*480*8bit, scrolling backgrounds? I dont think I've ever seen
such a game for the mac.  Obviously copy-bits can't handle that.  I'm
working on a custom blitter, but is it even possible without learning
assembler?  I'm a computer art student and fairly new to programing. I
want to do this as part of my thesis but I am afraid I might be getting in
over my head. Whaddayathink? Opinions and advice are greatly appreciated.

                                                   Z.Brill

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Wed, 17 Apr 1996 18:00:31 -0400
Organization: Carnegie Mellon, Pittsburgh, PA

[e-mail] writes:
>    How difficult would it be to write an arcade style game that uses full
> screen, 640*480*8bit, scrolling backgrounds? I dont think I've ever seen
> such a game for the mac.

There are some. I wrote one. ("Icebreaker". Commercial, not
downloadable. There may still be a demo around somewhere.)

> Obviously copy-bits can't handle that.

You'd be surprised. Icebreaker uses custom blitters for sprites, and
then uses CopyBits to get it from the GWorld to the screen. It got 15
or more fps on Quadras, 18 or more on PowerMacs. Kind of ugly on my
home Mac (Centris 610, a 68040LC chip) though.

> I'm
> working on a custom blitter, but is it even possible without learning
> assembler?

The custom blitters were not written in assembly, but I did write the
code with careful consideration to what kind of assembly it would
compile into.

At any rate, there are several sprite and blitting packages orbiting
the Mac shareware community. Look on Info-Mac in the development
directory.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."


+++++++++++++++++++++++++++

>From [e-mail] (Trevor Powell)
Date: Thu, 18 Apr 1996 11:03:32 +1000
Organization: Vulpine Software

In article <[e-mail]>, [e-mail] wrote:

> Okay here goes...
>    How difficult would it be to write an arcade style game that uses full
> screen, 640*480*8bit, scrolling backgrounds? I dont think I've ever seen
> such a game for the mac.  Obviously copy-bits can't handle that.  I'm
> working on a custom blitter, but is it even possible without learning
> assembler?  I'm a computer art student and fairly new to programing. I
> want to do this as part of my thesis but I am afraid I might be getting in
> over my head. Whaddayathink? Opinions and advice are greatly appreciated.

Answer.  "Pretty hard".  I've never even seen such a game for the PC.

Now, having said that, I've seen a demo by Andrew Welch (answers: 'no',
'no', and 'not yet' respectively, by the way, for those who were curious.
So eager API-authors, wives-to-be, and sanitarium owners know who to
target.  ;) ) which did interactive 8-bit graphic scrolling, with an
overlay of 16 partially overlapping Maelstrom ships, in a window of about
400x400 pixels.  Maybe a bit bigger than that.  (The background image
scrolled as you moved the mouse, with the rotating Maelstrom ships drawn
above the background)

It ran smooth as silk on my 68040.. and quite acceptably on my old 68020
vanilla Mac II...  Who knows -- maybe with a PPC Andrew'll figure out a
good way to do real full screen scrolling..

+++++++++++++++++++++++++++

>From [e-mail] (Christoph Bergmann)
Date: Thu, 18 Apr 1996 10:32:45 +1000
Organization: University of Queensland

In article <[e-mail]>, [e-mail] wrote:

> Okay here goes...
>    How difficult would it be to write an arcade style game that uses full
> screen, 640*480*8bit, scrolling backgrounds? I dont think I've ever seen
> such a game for the mac.  Obviously copy-bits can't handle that.  I'm
> working on a custom blitter, but is it even possible without learning
> assembler?  I'm a computer art student and fairly new to programing. I
> want to do this as part of my thesis but I am afraid I might be getting in
> over my head. Whaddayathink? Opinions and advice are greatly appreciated.
>
>                                                    Z.Brill

hard? no. slow? quite possibly. on a mid-high end powermac, something like
this should be possible. on a low-end, it may be possible, but would
probably be a little slow. on an 040, forget it ;)

use copybits for any full copies (assuming you use an offscreen->screen
blit) and write your own blitters for sprites etc.

heck, if 320x200x16 can be done on an 030/33, a powermac shouldnt have
tooo much trouble doing it at higher qual..


chris

+++++++++++++++++++++++++++

>From [e-mail] (Scott Squires)
Date: Wed, 17 Apr 1996 17:40:33 -0800
Organization: Puffin Designs

In article <[e-mail]>,
[e-mail] wrote:

>Okay here goes...
>   How difficult would it be to write an arcade style game that uses full
>screen, 640*480*8bit, scrolling backgrounds? I dont think I've ever seen
>such a game for the mac.  Obviously copy-bits can't handle that.  I'm
>working on a custom blitter, but is it even possible without learning
>assembler?  I'm a computer art student and fairly new to programing. I
>want to do this as part of my thesis but I am afraid I might be getting in
>over my head. Whaddayathink? Opinions and advice are greatly appreciated.


Check out 'CopyBits ColorKarma', this is Apple demo code from Develop
magazine Vol 17.  It should be in the Apple Developer's web site.
Unfortunately it hasn't been updated to the new Universal Headers.

-scott


Scott Squires               "Insert funny stuff here"
[e-mail]
[e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (Joshua Grass)
Date: 18 Apr 1996 17:35:39 GMT
Organization: University of Massachussetts Computer Science Department

In article <[e-mail]>,
 <[e-mail]> wrote:
>Okay here goes...
>   How difficult would it be to write an arcade style game that uses full
>screen, 640*480*8bit, scrolling backgrounds? I dont think I've ever seen
>such a game for the mac.  Obviously copy-bits can't handle that.  I'm
>working on a custom blitter, but is it even possible without learning
>assembler?  I'm a computer art student and fairly new to programing. I
>want to do this as part of my thesis but I am afraid I might be getting in
>over my head. Whaddayathink? Opinions and advice are greatly appreciated.
>
>                                                   Z.Brill

I've written a program that does the following:

Draws around 40 sprites to an offscreen image: tiling the floor, and
drawing characters.  Uses a custom blitter, for 8-bit transparency
coloring, but also keeps track of the start and end for each row, so
it skips a lot of empty space on the edges(most sprites have no empty
middles, so the real trick is to just keep track of the start and end
positions of the bytes to draw).

Used copybits to slam the offscreen to the main screen.

Also did some other drawing(status bars, etc...).

Now on a 6100/66 PPC I got a frame rate of ~15fps for an area 320x460
at 256 colors.  You might be able to improve the blitter a little by
encoding the sprites to take advantage of 8 byte draws, but the
checking may take nearly as much time as you save.  I'll have to think
about how to encode on the fly(I don't like the pre-encoding idea put
forth in Tricks...).

Anyway, you can look at my sprite drawing and encoding code at the
following web address:

http://anytime.cs.umass.edu/jgrass-bin/question?question00046

Let me also plug my HIT on mac-programming at the address:

http://anytime.cs.umass.edu/~jgrass/MGPW/index.html

It's a web system for asking and answering questions about mac game
programming, and keeping a history of the responses.

                        Joshua

--
If you want to know who you are,        | [e-mail]
it's important to know who you've been. | http://anytime.cs.umass.edu/~jgrass



+++++++++++++++++++++++++++

>From [e-mail] (Vern Jensen)
Date: 18 Apr 1996 02:04:24 GMT
Organization: NETCOM Network Operations

In article <[e-mail]>, [e-mail] wrote:

> Okay here goes...
>    How difficult would it be to write an arcade style game that uses full
> screen, 640*480*8bit, scrolling backgrounds? I dont think I've ever seen
> such a game for the mac.  Obviously copy-bits can't handle that.  I'm
> working on a custom blitter, but is it even possible without learning
> assembler?  I'm a computer art student and fairly new to programing. I
> want to do this as part of my thesis but I am afraid I might be getting in
> over my head. Whaddayathink? Opinions and advice are greatly appreciated.
>
>                                                    Z.Brill


I'd suggest getting SpriteWorld 2.0, which I'm currently working on along
with Karl Bunker. A beta should be ready very soon. Anyway, SpriteWorld
2.0 sports some brand new scrolling and tiling routines, that are as fast
as anything you'll find (and usually faster).

In a 640*480 window in 256 colors, I get 12 fps when interlacing on an LC
II. This may seem slow, but remember that this is an LC II! On 68040 Macs
it goes much faster, like around 30fps or more. And of course on the
PowerMac, it goes really fast. On a Power Mac 8100, in 256 colors with a
640x480 window, SpriteWorld gets the following frame rates:

    68K (running under emulation):
        Not interlaced:    43
        Interlaced:        52

    PPC (native):
        Not interlaced:    67
        Interlaced:        136

And of course, if you use a smaller window, like 512x384, then things go
*much* faster.

Anyone interested in beta testing SpriteWorld 2.0 can write to me and tell
me their name, type of Mac, and the compiler they use. The beta will be
emailed to everyone on the list as soon as it is ready, which will
hopefully be in about a week.

-Vern


+++++++++++++++++++++++++++

>From [e-mail] (David Wareing)
Date: Thu, 18 Apr 1996 13:04:45 +0930
Organization: Weyland Yutani

In article <[e-mail]>, [e-mail] wrote:

>Okay here goes...
>   How difficult would it be to write an arcade style game that uses full
>screen, 640*480*8bit, scrolling backgrounds? I dont think I've ever seen
>such a game for the mac.  Obviously copy-bits can't handle that.  I'm
>working on a custom blitter, but is it even possible without learning
>assembler?  I'm a computer art student and fairly new to programing. I
>want to do this as part of my thesis but I am afraid I might be getting in
>over my head. Whaddayathink? Opinions and advice are greatly appreciated.

640x480x8 @ 30FPS can certainly be done on a PowerMac but remember
that CopyBits is only one part of the equation. In many fullscreen
animation cases you might only use CopyBits once for the final blit to
screen.

Get your game working first with CopyBits and then work on improving that
final blit if necessary.  And don't get your hopes up too high. Are you
prepared to spend 50% of your effort just to get a 5% speed increase,
if that?

There are plenty of other aspects of a scrolling game which can have
a large impact upon speed, including your background scrolling/updating
mechanisms, sprite composition, sound, music, game AI & logic,
collision detection, and so on.

I'd venture to say that the mechanism for your background scrolling
and updating is much more important than the issue of CopyBits vs a
custom blitter. For a Xevious/Raiden type of top-down scroller, for
instance, your choice of scrolling/updating algorithm can instantly
double the speed of your game, or halve it...

--
David Wareing                                 [e-mail]
Belair, South Australia           http://www.AmbrosiaSW.com/~dwareing/
Macintosh & BeBox Games Development



+++++++++++++++++++++++++++

>From Mikael Bouillot <[e-mail]>
Date: 19 Apr 1996 11:38:17 GMT
Organization: Robins AFB, GA

In c.s.m.p.games, [e-mail] wrote:

> How difficult would it be to write an arcade style game that uses full
> screen, 640*480*8bit, scrolling backgrounds? I dont think I've ever seen
> such a game for the mac.  Obviously copy-bits can't handle that.  I'm
> working on a custom blitter, but is it even possible without learning
> assembler?  I'm a computer art student and fairly new to programing. I
> want to do this as part of my thesis but I am afraid I might be getting in
> over my head. Whaddayathink? Opinions and advice are greatly appreciated.

 I've done a tiny little thing that does a 640x480x8bit scrolling based on
tiles, and runs at 67 fps (sync'd to the screen VBL) on my 7200/75. It's 100%
pure C, with no assembly in it and it's pretty ugly to read, because it was
just done to show my Amiga and PC friends that the Mac was capable of it, but
at least (and unlike many of my progs) it works.

 If I had a 64 bits data path to my VRAM (which I would get with 2 Mb, if I
understood well), it would even do 640x480x16bits at 67 fps, but right now, it
only fills 90% of the screen with 16bits tiles :..-(

 I'll post the heart of my app when I come back.

 Mikael Bouillot

 [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Dmitry Boldyrev)
Date: Thu, 18 Apr 1996 11:31:38 -0600
Organization: Xenix Demo Group

In article <[e-mail]>,
[e-mail] (Vern Jensen) wrote:

Wish only Apple computers could do true VBL synching. Life would be a lot
simplier for game developers.

Ugh

Demos

--
Demos

+++++++++++++++++++++++++++

>From Omeed Fanaian <[e-mail]>
Date: Fri, 19 Apr 1996 13:50:26 -0500
Organization: Bell Northern Research

Vern Jensen wrote:

> I'd suggest getting SpriteWorld 2.0, which I'm currently working on along
> with Karl Bunker. A beta should be ready very soon. Anyway, SpriteWorld
> 2.0 sports some brand new scrolling and tiling routines, that are as fast
> as anything you'll find (and usually faster).

Whatever happened to Tony Myles? Wasn't he the one that was working on that?

O.

+++++++++++++++++++++++++++

>From [e-mail] (Juri Munkki)
Date: 19 Apr 1996 22:36:37 GMT
Organization: Helsinki University of Technology

In article <[e-mail]> [e-mail] (Dmitry Boldyrev) writes:
>Wish only Apple computers could do true VBL synching. Life would be a lot
>simplier for game developers.

Exsqueeze me???

I think the Macintosh is one of the few computers there that has built-in
support for synching to multiple connected screens.

--
Juri Munkki [e-mail]        Life is easy when polygons are cheap.
http://www.iki.fi/jmunkki           Windsurfing: Faster than the wind.


+++++++++++++++++++++++++++

>From [e-mail] (Alex Rosenberg)
Date: Sat, 20 Apr 1996 20:23:05 -0500
Organization: Hackers Anonymous

In article <[e-mail]>, [e-mail] wrote:

>   How difficult would it be to write an arcade style game that uses full
>screen, 640*480*8bit, scrolling backgrounds? I dont think I've ever seen
>such a game for the mac.  Obviously copy-bits can't handle that.

Power Pete scrolls most of a 640x480 screen just fine. I helped Brian
tweak that at the first Apple Game Kitchen.

- ----------------------------------------------------
|  Alexander M. Rosenberg   <mailto:[e-mail]>|
|  Bungie Software          <http://www.bungie.com>  |
|  Nobody cares what I say.                          |

+++++++++++++++++++++++++++

>From Dave Howell <[e-mail]>
Date: Wed, 24 Apr 1996 02:23:22 -0700
Organization: Pablo Media

[e-mail] wrote:
>
>How difficult would it be to write an arcade style game that uses full
>screen, 640*480*8bit, scrolling backgrounds?

On what machines? A Mac LC? Very difficult.

>I dont think I've ever seen
>such a game for the mac.  Obviously copy-bits can't handle that.

You'd be surprised. I've worked on projects where we thought we could do
a faster blit than CopyBits could, and it's quite difficult. CopyBits is
pretty well optimized if you call it just right. It's smart enough to
use unrolled loops of MOVE16 instructions on an 040 whenever possible,
and it is plenty fast on the PowerPC. And if you are blitting from a
QuickDraw accelerated video card onto that card's display buffer, you
don't want to use your code.

No, use CopyBits. You just have to make sure that when you call
CopyBits, everything is set up so that it doesn't have to remap palettes
or shift longwords or anything like that. If you really do need to write
your own blitter, make sure you let the user opt to use CopyBits just in
case your blitter is incompatible with his video card, or ends up being
slower than CopyBits on his configuration.

>I'm
>working on a custom blitter, but is it even possible without learning
>assembler?

It would be very difficult to write a better blitter than CopyBits in C.

>I'm a computer art student and fairly new to programing. I
>want to do this as part of my thesis but I am afraid I might be getting
>in over my head. Whaddayathink? Opinions and advice are greatly
>appreciated.
>
>                                                    Z.Brill

My vote sez, use your own code up until the point where it's time to
blit to the screen. Then use CopyBits for that last blit.

Dave Howell
Pablo Media

+++++++++++++++++++++++++++

>From Dave Howell <[e-mail]>
Date: Wed, 24 Apr 1996 02:25:21 -0700
Organization: Pablo Media

[e-mail] wrote:
>
>How difficult would it be to write an arcade style game that uses full
>screen, 640*480*8bit, scrolling backgrounds?

On what machines? A Mac LC? Very difficult.

>I dont think I've ever seen
>such a game for the mac.  Obviously copy-bits can't handle that.

You'd be surprised. I've worked on projects where we thought we could do a
faster blit than CopyBits could, and it's quite difficult. CopyBits is
pretty well optimized if you call it just right. It's smart enough to use
unrolled loops of MOVE16 instructions on an 040 whenever possible, and it is
plenty fast on the PowerPC. And if you are blitting from a QuickDraw
accelerated video card onto that card's display buffer, you don't want to
use your code.

No, use CopyBits. You just have to make sure that when you call CopyBits,
everything is set up so that it doesn't have to remap palettes or shift
longwords or anything like that. If you really do need to write your own
blitter, make sure you let the user opt to use CopyBits just in case your
blitter is incompatible with his video card, or ends up being slower than
CopyBits on his configuration.

>I'm
>working on a custom blitter, but is it even possible without learning
>assembler?

It would be very difficult to write a better blitter than CopyBits in C.

>I'm a computer art student and fairly new to programing. I
>want to do this as part of my thesis but I am afraid I might be getting
>in over my head. Whaddayathink? Opinions and advice are greatly
>appreciated.
>
>                                                    Z.Brill

My vote sez, use your own code up until the point where it's time to blit to
the screen. Then use CopyBits for that last blit.

Dave Howell
Pablo Media

+++++++++++++++++++++++++++

>From [e-mail] (Mark Elliott)
Date: Thu, 25 Apr 1996 14:11:30 +0200
Organization: Max-Planck-Institut f. Kohlenforsch. Muelheim

In article <[e-mail]>, Dave Howell
<[e-mail]> wrote:


> It would be very difficult to write a better blitter than CopyBits in C.
>

Sorry Dave, but that is simply not true. I have a blitter which for 20 x
20 and 40 x 40 rects outperforms CopyBits by a long way (on 680x0 macs - I
still use the C version on powermacs, since it is safe and fast. I don't
know how well it would fare against CopyBits in this case). Although it is
now written in assembler, I first wrote it in C and it was still faster
than CopyBits - codewarrior optimised the code pretty well. I actually
only got a couple of % gain by coding in assembler - trust your compiler !

Mark

- ------------------------------------------------------------------
Mark C Elliott                           [e-mail]
Max-Planck-Institut                      voice: ([phone]
Fuer Kohlenforschung
Muelheim, Germany
- ------------------------------------------------------------------


+++++++++++++++++++++++++++

>From Dave Howell <[e-mail]>
Date: Thu, 25 Apr 1996 22:23:30 -0700
Organization: Pablo Media

Mark Elliott wrote:
> > It would be very difficult to write a better blitter than CopyBits
> > in C.
>
> Sorry Dave, but that is simply not true. I have a blitter which for
> 20 x 20 and 40 x 40 rects outperforms CopyBits by a long way (on
> 680x0 macs - I still use the C version on powermacs, since it is
> safe and fast. I don't know how well it would fare against CopyBits
> in this case). Although it is now written in assembler, I first
> wrote it in C and it was still faster than CopyBits - codewarrior
> optimised the code pretty well. I actually only got a couple of %
> gain by coding in assembler - trust your compiler !
>
> Mark

Well, I believe that you really did write that function, and that it
really was faster on your machine. You had a very special-case
scenario, and a very special-case benchmark. CopyBits is slow for very
small rectangles, such as those you were testing. Because CopyBits
handles so many special cases (blitting to a window spanning multiple
graphics devices, special modes like xor and matting, masking, etc),
the overhead becomes non-negligible at small resolutions. The trouble is
writing a general-purpose blitter that is faster on all machines. Did
you try running yours on a machine with a graphics accelerator card?

That all being said, in some games and QuickTime codecs we did end up
shipping our own blitters for special cases. One case where CopyBits is
horribly slow and we were nice and fast is the case of pixel-doubling a
320x240 8-bpp bitmap to a screen at 640x480. We were able to read a
16-bit word, use 68K bit-field extract instructions to duplicate it in a
32-bit register, and write it into two destination lines at once. In the
PowerPC version, we just used C because it was plenty fast enough for
our animations.

Yes, you can write faster blitters than CopyBits for special purposes.
And games are generally special purpose. You can even write them in C,
but you still need to know assembly well enough to examine the compiled
code and look for redundancy and inefficiency.

Dave Howell
Pablo Media

+++++++++++++++++++++++++++

>From [e-mail] (Marko Horvatic)
Date: 26 Apr 1996 10:56:36 GMT
Organization: University of Zagreb, Dept. of Mathematics

Omeed Fanaian ([e-mail]) wrote:
: Vern Jensen wrote:

: > I'd suggest getting SpriteWorld 2.0, which I'm currently working on along
: > with Karl Bunker. A beta should be ready very soon. Anyway, SpriteWorld
: > 2.0 sports some brand new scrolling and tiling routines, that are as fast
: > as anything you'll find (and usually faster).

 Is SW 2.0 going to be PPC only or is there going to be a 680x0 option?

 Are you going to make any Pascal libraries or only C ones?
 p
 Is it going to be CW or Symantect C/C++ 8.0 lybraries?

 Thanks
 M.
--
******************************************************************************
    Marko Horvatic
    E-mail  [e-mail]
    WWW     http://student.math.hr/~mhzujo
******************************************************************************

+++++++++++++++++++++++++++

>From [e-mail] (KarlBunker)
Date: 28 Apr 1996 10:46:32 -0400
Organization: America Online, Inc. (1-800-827-6364)

Marko Horvatic wrote:

> Is SpriteWorld 2.0 going to be PPC only or is there going to be a 680x0
option?
> Is it going to be CW or Symantec C/C++ 8.0 libraries?

We will be distributing the source and libraries as well. The source will
be PPC and 68K compilable, with some conditional-compiling optimizations
for each type of compile. The libraries will (most likely) be available
for the following environments:
68K Symantec C/C++
68K CW C/C++
PPC CW C/C++

 > Are you going to make any Pascal libraries or only C ones?

The source is C; it may be possible to compile libraries usable from
Pascal, but I don't know.

Karl Bunker
[e-mail]
http://users.aol.com/karlbunker/


+++++++++++++++++++++++++++

>From "Ian K. Erickson" <[e-mail]>
Date: Wed, 1 May 1996 22:47:14 PST
Organization: A poorly-installed InterNetNews site

On 28 Apr 1996, KarlBunker wrote:
>  > Are you going to make any Pascal libraries or only C ones?
> The source is C; it may be possible to compile libraries usable from
> Pascal, but I don't know.

I know THINK pascal can use THINK C libraries, but I don't know about CW.

   o   \ o /   __o          __|     \/      |__        o__   \ o /  o
  /|\    |      /|   __\o      \o    |    o/    o/__   |\      |   /|\
  / \   / \    |\  /)  |       ( \  /o\  / )     |  (\  / \   / \  / \
=================http://www.labs.ewu.edu/Cons/ierickson/ierickson.htm===========
Ian K. Erickson       "The Latin word for 'Close your eyes and open your mouth'
[e-mail]      is Prospectus." - Dogbert the Almighty.


---------------------------

>From [e-mail] (Spencer)
Subject: Getting Partition Info (as opposed to volume...)
Date: Fri, 03 May 1996 12:40:41 -0400
Organization: Spencer

Hi,

I suspect this is FAQ, but if someone could tell me how to search/get info
on a partition rather than a complete volume I'd be most appreciative.
Seems like PBCatSearch and PBHGetVInfoSync work while whole volumes, while
I want to limit actions to volume partitions. Any pointers, would be
greatly appreciated. (especially by e-mail: [e-mail])

Thanks, Spencer

+++++++++++++++++++++++++++

>From [e-mail]
Date: Fri, 03 May 1996 19:59:54 -0700
Organization: CCnet Communications (510-988-7140 guest)

In article <[e-mail]>,
[e-mail] (Spencer) wrote:

>I suspect this is FAQ, but if someone could tell me how to search/get info
>on a partition rather than a complete volume I'd be most appreciative.

You use the driver-level PBRead to directly read block 1 of the drive.
That's the first parition map entry.  You can then calculate the next
partition map entry from the offset and size.  See Inside
Macintosh:Devices for details.

---------------------------

>From [e-mail] (Joel Quejada)
Subject: Getting monitor's scan rate?
Date: 1 May 1996 20:26:37 GMT
Organization: Texas Instruments, Inc.

Can anyone describe (with code if possible) what the best way to find
out what a particular monitor's refresh rate is?

I am currently doing this by installing a VBL task into the device I
want, entering a tight loop for 1 (or 2) seconds, and count how many
times my task was called. Kinda cheesy, but it works OK. I was just
wondering if there was a more direct way to do this.

Thanks,

Joel

+++++++++++++++++++++++++++

>From Dave Howell <[e-mail]>
Date: Wed, 01 May 1996 14:07:51 -0700
Organization: Pablo Media

Joel Quejada wrote:
>
> Can anyone describe (with code if possible) what the best way to find
> out what a particular monitor's refresh rate is?
>
> I am currently doing this by installing a VBL task into the device I
> want, entering a tight loop for 1 (or 2) seconds, and count how many
> times my task was called. Kinda cheesy, but it works OK. I was just
> wondering if there was a more direct way to do this.

Joel, that sounds like a good approach, particularly because it applies
to any platform and will work on PCs, Macs, or whatever. Just don't stop
while this is going on. Have it take place during the first couple of
seconds of game play, possibly during your intro.

Keep in mind though, if you change resolutions during the game, that the
refresh rate will probably change as the resolution does.

Dave
 ____________________ ___     _   _      ____________________
|                    | _ \___| |_| | ___|                    |
|    Dave Howell     |  _/ _ | _ \ |/ _ \     Pablo Media    |
|____________________|_| \___|___/_|\___/____________________|

+++++++++++++++++++++++++++

>From [e-mail] (Scott Squires)
Date: Thu, 02 May 1996 07:48:25 -0800
Organization: Puffin Designs

In article <4m8hdt$[e-mail]>,
[e-mail] (Joel Quejada) wrote:

>Can anyone describe (with code if possible) what the best way to find
>out what a particular monitor's refresh rate is?
>
>I am currently doing this by installing a VBL task into the device I
>want, entering a tight loop for 1 (or 2) seconds, and count how many
>times my task was called. Kinda cheesy, but it works OK. I was just
>wondering if there was a more direct way to do this.
>


Check out the DisplayManager, I think it provides a way to do it.
You could also check VideoToolBox code.  (Avail. at Mac ftp sites)

-scott



Scott Squires               "Insert funny stuff here"
[e-mail]
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Cary Farrier)
Date: Thu, 02 May 1996 07:15:11 -0700
Organization: Apple Computer, Inc.

In article <4m8hdt$[e-mail]>, [e-mail] (Joel Quejada) wrote:
> I am currently doing this by installing a VBL task into the device I
> want, entering a tight loop for 1 (or 2) seconds, and count how many
> times my task was called. Kinda cheesy, but it works OK. I was just
> wondering if there was a more direct way to do this.

This is what DrawSprocket must do when it can't map the video mode
constant to the values in <Video.h>.  If it can map the mode value,
then it will return the constant instead.

-> Cary

--
- -------------------------------------------------------------------
Cary Farrier, aka Mr. DrawSprocket
Software Engineer, Apple Game Technology Group
[e-mail]

---------------------------

>From [e-mail] (Tim DeBenedictis)
Subject: Is there a "bad" fileRefNum value?
Date: Wed, 24 Apr 1996 16:47:42 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

A file reference number (as returned by FSOpen(), etc.) is just a 16-bit
integer.  As far as I know, this integer can take any value from -32768 to
32767.  However, is there any value I can use to indicate a "bad" file
reference number?  This value would have to be one which was never
normally returned by FSOpen().  (Can FSOpen() ever return a fileRefNum
of zero?)

The reason I ask is that I need to write a wrapper around FSOpen(), and
the wrapper must return the fileRefNum if successful or an unambiguous
error value on failure.  I can't have the error code separate from the
fileRefNum, as FSOpen does.

Thanks in advance,

-Tim DeBenedictis
[e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 25 Apr 1996 10:13:59 GMT
Organization: Ecole Normale Superieure, Paris

In article <[e-mail]>,
Tim DeBenedictis <[e-mail]> wrote:

>The reason I ask is that I need to write a wrapper around FSOpen(), and
>the wrapper must return the fileRefNum if successful or an unambiguous
>error value on failure.  I can't have the error code separate from the
>fileRefNum, as FSOpen does.

I think -1 is usually used as an invalid refNum. But if you're
doing C++, throwing an exception would be much better style...

--
Francois Pottier
[e-mail]
[e-mail]
http://www.eleves.ens.fr:8080/home/pottier/

+++++++++++++++++++++++++++

>From [e-mail] (Patrick Stadelmann)
Date: Thu, 25 Apr 1996 16:52:08 +0200
Organization: University of Neuchatel

In article <[e-mail]>, [e-mail] (Tim
DeBenedictis) wrote:

> A file reference number (as returned by FSOpen(), etc.) is just a 16-bit
> integer.  As far as I know, this integer can take any value from -32768 to
> 32767.  However, is there any value I can use to indicate a "bad" file
> reference number?  This value would have to be one which was never
> normally returned by FSOpen().  (Can FSOpen() ever return a fileRefNum
> of zero?)
>
> The reason I ask is that I need to write a wrapper around FSOpen(), and
> the wrapper must return the fileRefNum if successful or an unambiguous
> error value on failure.  I can't have the error code separate from the
> fileRefNum, as FSOpen does.

fileRefNums are always positive. Negative (including zero) fileRefNums
are invalid. Some Toolbox calls returns a fileRefNum of -1 to indicate
failure (eg, OpenResFile)

Patrick

--
Patrick Stadelmann <[e-mail]>

+++++++++++++++++++++++++++

>From [e-mail] (Christopher Swan)
Date: Sun, 28 Apr 1996 23:46:39 +1200
Organization: Raine Storm Softworks

>>The reason I ask is that I need to write a wrapper around FSOpen(), and
>>the wrapper must return the fileRefNum if successful or an unambiguous
>>error value on failure.  I can't have the error code separate from the
>>fileRefNum, as FSOpen does.
>
>I think -1 is usually used as an invalid refNum. But if you're
>doing C++, throwing an exception would be much better style...

There's a tech note somewhere that says to use 0 and explains why.

--

Cheers, Chris

- ---------------------------------------------------------------------
Christopher Swan                                 CompuServe 100354,3427
PO Box 11567, Wellington, New Zealand                 or [e-mail]
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Dr. Benway)
Date: Sun, 28 Apr 1996 17:48:25 -0500
Organization: Interzone

In article <[e-mail]>,
[e-mail] (Christopher Swan) wrote:

[ snip, snip, snip ]

> There's a tech note somewhere that says to use 0 and explains why.
>
> --
>
> Cheers, Chris
>
> -----------------------------------------------------------------------
> Christopher Swan                                 CompuServe 100354,3427
> PO Box 11567, Wellington, New Zealand                 or [e-mail]
> -----------------------------------------------------------------------

Yep, Tech Note FL 22, entitled "HFS Ruminations". Go to
http://dev.info.apple.com/technotes/Main.html and search for "vRefNum".

--
Dr. Benway :::::::::::::::::::: Interzone
=========================================
*   A roadkill on the highway of love.  *
=========================================
*         [e-mail]         *
*  http://www.cu-online.com/~browning/  *
=========================================

+++++++++++++++++++++++++++

>From [e-mail] (Peter Bromley)
Date: Wed, 01 May 1996 16:04:46 +1200
Organization: ADInstruments

In article <drbenway-2804961748250001@bville-pm2-2/141.accessus.net>,
[e-mail] (Dr. Benway) wrote:

> In article <[e-mail]>,
> [e-mail] (Christopher Swan) wrote:
>
> [ snip, snip, snip ]
>
> > There's a tech note somewhere that says to use 0 and explains why.
> >
> > --
> >
> > Cheers, Chris
> >
> > -----------------------------------------------------------------------
> > Christopher Swan                                 CompuServe 100354,3427
> > PO Box 11567, Wellington, New Zealand                 or [e-mail]
> > -----------------------------------------------------------------------
>
> Yep, Tech Note FL 22, entitled "HFS Ruminations". Go to
> http://dev.info.apple.com/technotes/Main.html and search for "vRefNum".


Sorry, guys, you both replied too fast.

That technote refers to volume refNums (vRefNum).
The original poster wants to know what is a "bad" FILE refNum.

I use -1 in all my code. In fact I have defined a constant which I use.

badFileNum  = -1;   { Pascal }
--
Peter Bromley                                  ([e-mail])
ADInstruments, Dunedin, New Zealand

+++++++++++++++++++++++++++

>From [e-mail] (Steve Kiene)
Date: Wed, 01 May 1996 18:52:44 -0600
Organization: MindVision Software

In article <[e-mail]>, [e-mail] (Tim
DeBenedictis) wrote:

> A file reference number (as returned by FSOpen(), etc.) is just a 16-bit
> integer.  As far as I know, this integer can take any value from -32768 to
> 32767.  However, is there any value I can use to indicate a "bad" file
> reference number?  This value would have to be one which was never
> normally returned by FSOpen().  (Can FSOpen() ever return a fileRefNum
> of zero?)
>
> The reason I ask is that I need to write a wrapper around FSOpen(), and
> the wrapper must return the fileRefNum if successful or an unambiguous
> error value on failure.  I can't have the error code separate from the
> fileRefNum, as FSOpen does.

A little explaination on how the System generates file refNums:

File refNums are simply an offset into a block containing File Control
Blocks (FCB). The structure of the FCB is:

{
short size;
FCB   theFCBs[0..0];
}

So, the first file opened has a refNum of 2 (2 bytes into the structure,
past the size).

Each additional refNum is found by adding the size of the FCB structure.

To (finally) answer your question, -1, 0, 1, 3, 4, etc. are all invalid
file refNums. Any number except multiples of the FCB size + 2 are valid.

Keep in mind the volume refNums are negative and start at -1. So I would
use 1 if there is a chance that you might be working with a volume refNum
(zero generally indicates the default volume).

Hope this helps.

Steve Kiene
MindVision Software

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 3 May 1996 04:46:37 -0400
Organization: America Online, Inc. (1-800-827-6364)

Tim DeBenedictis wrote:
>A file reference number (as returned by FSOpen(), etc.) is just
>a 16-bit  integer.  As far as I know, this integer can take any
>value from -32768 to 32767.  However, is there any value I can
>use to indicate a "bad" file  reference number?  This value
>would have to be one which was never  normally returned by
>FSOpen().  (Can FSOpen() ever return a fileRefNum  of zero?)
>
>The reason I ask is that I need to write a wrapper around
>FSOpen(), and  the wrapper must return the fileRefNum if
>successful or an unambiguous  error value on failure.  I can't
>have the error code separate from the  fileRefNum, as FSOpen
>does.

Actually, File Manager reference numbers are always *positive* 2-byte
integers. Negative reference numbers returned by _Open are device driver
reference numbers.

So yes, you could use 0 to indicate that the file wasn't opened. However,
I think it's better style for File Manager related functions to return an
OSErr as the function result and not overload the use of the reference
number.

- Jim Luther

---------------------------

>From [e-mail] (Adriaan Tijsseling)
Subject: Mac Tutorials Here!
Date: Wed, 01 May 1996 20:23:24 +0000
Organization: Electronics and Computer Science, University of Southampton


Hi,

Found this great site containing an extensive introduction to
Mac Programming. Complete with source codes. The best I've seen!

Go:

http://www.AmbrosiaSW.com/alt.sources.mac/macintosh-c/


Enjoy,

Adriaan

---------------------------

>From Steve - The Mac - Watson <[e-mail]>
Subject: Overlaying a PICT onto a background
Date: Mon, 29 Apr 1996 09:43:43 +0100
Organization: MICAbuild Limited

I have a PICT image whose background is white. I am using DrawPicture()
to place it onto a black background, but the white gets copied as well -
rather like cutting out a piece of paper and sticking it on.

What I want is to have only the image appear - that is, surrounded by
black. I have tried using PenMode(srcBic) and PenMode(transparent +
srcCopy) and various others I've forgotten but I just get the same
result.

Is using PenMode the correct way to do this or should I be using some other
calls?

Thanks for any help.

+++++++++++++++++++++++++++

>From "Edward Voas" <[e-mail]>
Date: 1 May 96 19:28:34 +0000
Organization: Shore.Net/Eco Software, Inc; ([e-mail])

>What I want is to have only the image appear - that is, surrounded by
>black. I have tried using PenMode(srcBic) and PenMode(transparent +
>srcCopy) and various others I've forgotten but I just get the same
>result.
>
>
>Is using PenMode the correct way to do this or should I be using some
other
>calls?
>

The only way I know how to accomplish this is to call DrawPicture onto an
offscreen GWorld and then copybits it to the screen using the transparent
mode. I hope when you mentioned you were using transparent + srcCopy, that
you weren't really adding them.

Ed Voas

+++++++++++++++++++++++++++

>From [e-mail] (John S. Heaney)
Date: 2 May 1996 15:17:58 -0700
Organization: CRL Dialup Internet Access    [phone]  [Login: guest]

In article <ADAD6BE6-137AE3@198.115.181.209>,
Edward Voas <[e-mail]> wrote:
>>What I want is to have only the image appear - that is, surrounded by
>>black. I have tried using PenMode(srcBic) and PenMode(transparent +
>>srcCopy) and various others I've forgotten but I just get the same
>>result.
>
>The only way I know how to accomplish this is to call DrawPicture onto an
>offscreen GWorld and then copybits it to the screen using the transparent
>mode.

This is also the way I do it, but I have successfully used Resorcerer to
decompose the PICT structure and change the transfer mode. I don't
generally do it this way because I often use PICT file instead of PICT
resources. In order to satisfy Resourcerer's template I have to delete
the first 512 bytes, make the change and insert 512 bytes. I also have to
make a synonym of the data fork to make it appear as a PICT resource.
It's probably not nearly as bad if you are using PICT resources.

I've had spotty results with Canvas, which gives you a great deal of
control over the way PICTs are built, but not in any obvious way.

>I hope when you mentioned you were using transparent + srcCopy, that
>you weren't really adding them.

Since srcCopy is 0, it shouldn't hurt. It makes more sense to 'or' them,
though.
--
John Heaney              Time flies whether you're having fun or not.
[e-mail]


---------------------------

>From [e-mail] (Jonathan Baumgartner)
Subject: Preventing Aliases from being automatically resolved?
Date: Mon, 29 Apr 1996 13:26:21 -0400
Organization: Cabletron Systems Inc.

I would like to be able to open aliases with CustomGetFile as aliases,
without the system automatically resolving them and returning the original
file. I'd also like to be able to do this from inside my Open Documents
handler function.

I know this can be done, since ResEdit allows it, as does StuffIt. Could
someone point me in the right direction?

thanks,
jon
--
Jonathan Baumgartner           "Duct tape is like the Force.  It has a light
[e-mail]                  side, a dark side, and it holds the universe
                                together." -- Carl Zwanzig

+++++++++++++++++++++++++++

>From [e-mail] (Dave Besbris)
Date: Wed, 01 May 1996 21:31:39 -0700
Organization: Delta Internet Services, Anaheim, CA

In article <[e-mail]>, [e-mail]
(Jonathan Baumgartner) wrote:

> I would like to be able to open aliases with CustomGetFile as aliases,
> without the system automatically resolving them and returning the original
> file. I'd also like to be able to do this from inside my Open Documents
> handler function.
>
> I know this can be done, since ResEdit allows it, as does StuffIt. Could
> someone point me in the right direction?
>
> thanks,
> jon
> --
> Jonathan Baumgartner           "Duct tape is like the Force.  It has a light
> [e-mail]                  side, a dark side, and it holds the universe
>                                 together." -- Carl Zwanzig


You basically fake out StandardFile with a hook proc. When you get the
"openalias" command (sorry, but I'm away from any kind of header files)
remap it to the "openselection" command. There is a recent apple snippit
that does this. Check the developer web site: http://dev.info.apple.com or
the developer CD's.


happy hooking!

bez

[e-mail]

---------------------------

>From [e-mail] (Dr H.S. Field-Richards)
Subject: Restricting PBCatSearch to a single directory
Date: Wed, 01 May 1996 17:27:23 +0100
Organization: DRA

I want to restrict searching for files to a single directory rather
than have PBCatSearchSync search an entire volume. I am sure the
information is somewhere but I have not been able to find anything.

Can anyone help or supply examples?

Thanks in advance

Hugh Field-Richards

--
Hugh S. Field-Richards
DRA (RSRE), St Andrew's Road, Malvern, Worcs, WR14 3PS UK
Tel: [phone]   Fax: [phone]  Email: [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 3 May 1996 04:53:47 -0400
Organization: America Online, Inc. (1-800-827-6364)

Dr H.S. Field-Richards wrote:
>I want to restrict searching for files to a single directory
>rather than have PBCatSearchSync search an entire volume. I am
>sure the information is somewhere but I have not been able to
>find anything.
>
>Can anyone help or supply examples?

If you want to get the items of a specified directory *not including* any
of its sub-directories, you should enumerate through the directory using
indexed PBGetCatInfo calls. An example of that can be found in the
MoreFiles sample code
<ftp://members.aol.com/JumpLong/MoreFiles_1.4.2.sea.hqx> in the form of a
function named GetDirItems. Using indexed PBGetCatInfo calls is much
faster than PBCatSearch in this situation because the whole catalog
doesn't have to be read.

If you want to get the items of a specified directory *including* any of
its sub-directories, MoreFiles has two other routines you'll like:

The IndexedSearch function has a programming interface just like
PBCatSearchSync only it has an additional dirID parameter that lets you
specify the directory to start the search in.

Another function that might be used for this in MoreFiles is
IterateDirectory. IterateDirectory indexes through the specified directory
structure calling a function you supply once for each file or directory it
finds. You get to tell IterateDirectory how many subdirectories deep you
want to index through.

- Jim Luther

+++++++++++++++++++++++++++

>From "Edward Voas" <[e-mail]>
Date: 3 May 96 09:38:18 +0100
Organization: Shore.Net/Eco Software, Inc; ([e-mail])

>I want to restrict searching for files to a single directory rather
>than have PBCatSearchSync search an entire volume. I am sure the
>information is somewhere but I have not been able to find anything.
>
>Can anyone help or supply examples?
>

By specifying the fsSBFlParID bit in the ioSearchBits fiels and the
directoryID itself in ioFlParID in both the ioSearchInfo1 and ioSearchInfo2
param blocks, you can restrict the search to only files with a particular
parent ID. Obviously in the paramblock used in the CatSearch call, you can
specify the volume to search.

Something like:

CInfoPBRec        search1, search2;
CSParam        pb;
Ptr            buffer;
Ptr            myMatchArray;
short            maxHits = 10;

buffer = NewPtr( sizeof( FSSpec ) * maxHits );
myMatchArray = NewPtr( kOptBufferSize );

search1.hFileInfo.ioFlParID    = myFavoriteDirectory;
search2.hFileInfo.ioFlParID    = myFavoriteDirectory;

pb.ioCompletion         = NULL;
pb.ioNamePtr        = NULL;
pb.ioVRefNum        = myFavoriteVolume;
pb.ioMatchPtr        = myMatchArray;
pb.ioReqMatchCount     = maxHits;
pb.ioSearchBits        = fsSBFlParID + fsSBPartialName; // for example
pb.ioSearchInfo1        = &search1;
pb.ioSearchInfo2          = &search2;
pb.ioCatPosition.initialize = 0;
pb.ioOptBuffer        = buffer;
pb.ioOptBufferSize     = kOptBufferSize;

That's kinda the idea. I haven't actually compiled this and used it, but it
should be pretty  close. I actually have a nice C++ class that implements a
disk search.

Ed Voas

---------------------------

>From [e-mail] (David B. Zwiefelhofer)
Subject: SetApplLimit
Date: Tue, 23 Apr 1996 20:24:36 -0500
Organization: Utility Reduction Specialists, Inc.

      SetApplLimit(Ptr(GetApplLimit- extraBytes));

 I use the preceding line of code to set my stack size. Unfortunately, it
doesn't seem to work perfectly. If I set extraBytes to any value less than
24608 (including setting it to zero) I get a net change in stack size of
24608. If I set extraBytes to anything greater than 24608 (less than my
total partition size, of course) it works perfectly.


My application is an appe (FBA) and I thought that the default stack size
for an appe was 8K, but when I check it it is only 1960 bytes (1964 under
7.5.3) thus leading to my need to alter the stack size.

Can anyone tell me why I'm encountering such weirdness in stack sizes?

Thanks,

Dave

--
David B. Zwiefelhofer
Utility Reduction Specialists, Inc.
1605 Monroe Street, Suite 110
Madison, WI  53211-2052
[phone]
[phone] FAX

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 24 Apr 1996 09:33:12 GMT
Organization: Ecole Normale Superieure, Paris

In article <DaveZ-2304962024360001@msn_7_16.binc.net>,
David B. Zwiefelhofer <[e-mail]> wrote:

> If I set extraBytes to any value less than 24608 (including setting
> it to zero) I get a net change in stack size of 24608.

I think this behavior is documented. There is a low memory variable
called DfltStack (or something like that) which is the minimum stack
size accepted by SetApplLimit. As you have noticed, it is set to
24K by default. I think it is accepted practice to change the value
of this global, call SetApplLimit, then restore the global to its
previous value. I do this in my FBA and it works fine. I think the
tech note on FBAs mentions this (PS02?)

>My application is an appe (FBA) and I thought that the default stack size
>for an appe was 8K, but when I check it it is only 1960 bytes (1964 under
>7.5.3) thus leading to my need to alter the stack size.

As far as I know, the default stack size for FBAs is 2K which is way
insufficient.

--
Francois Pottier
[e-mail]
[e-mail]
http://www.eleves.ens.fr:8080/home/pottier/

+++++++++++++++++++++++++++

>From [e-mail] (David B. Zwiefelhofer)
Date: Thu, 25 Apr 1996 08:12:10 -0500
Organization: Utility Reduction Specialists, Inc.

In article <4lksgo$[e-mail]>, [e-mail] (Francois
Pottier) wrote:

> In article <DaveZ-2304962024360001@msn_7_16.binc.net>,
> David B. Zwiefelhofer <[e-mail]> wrote:
>
> > If I set extraBytes to any value less than 24608 (including setting
> > it to zero) I get a net change in stack size of 24608.
>
> I think this behavior is documented. There is a low memory variable
> called DfltStack (or something like that) which is the minimum stack
> size accepted by SetApplLimit. As you have noticed, it is set to
> 24K by default. I think it is accepted practice to change the value
> of this global, call SetApplLimit, then restore the global to its
> previous value. I do this in my FBA and it works fine. I think the
> tech note on FBAs mentions this (PS02?)
>

Thanks Francois, it worked like a charm. BTW, it is DefltStack and it is
at $31E.

-Dave

--
David B. Zwiefelhofer
Utility Reduction Specialists, Inc.
1605 Monroe Street, Suite 110
Madison, WI  53211-2052
[phone]
[phone] FAX

+++++++++++++++++++++++++++

>From [e-mail]
Date: Sun, 28 Apr 1996 16:42:19 -0700
Organization: CCnet Communications (510-988-7140 guest)

In article <DaveZ-2304962024360001@msn_7_16.binc.net>, [e-mail]
(David B. Zwiefelhofer) wrote:

>      SetApplLimit(Ptr(GetApplLimit- extraBytes));
>
> I use the preceding line of code to set my stack size. Unfortunately, it
>doesn't seem to work perfectly. If I set extraBytes to any value less than
>24608 (including setting it to zero) I get a net change in stack size of
>24608. If I set extraBytes to anything greater than 24608 (less than my
>total partition size, of course) it works perfectly.
>
>
>My application is an appe (FBA) and I thought that the default stack size
>for an appe was 8K, but when I check it it is only 1960 bytes (1964 under
>7.5.3) thus leading to my need to alter the stack size.
>
>Can anyone tell me why I'm encountering such weirdness in stack sizes?


See tech note PS 2, available at some URL such as
<http://dev.info.apple.com/technotes/Archive/Processes/ps_02.html>.  Also
see IM:Files Errata, also available at <http://dev.info.apple.com/>.

Faceless Background Applications by default get a 2K stack.  Other
applications get a 24K stack.  There's a low memory global which
determines how small you can make your stack if you change it.  I don't
remember if it's documented or not.

+++++++++++++++++++++++++++

>From [e-mail] (Jeremy Roussak)
Date: 30 Apr 1996 20:33:43 GMT
Organization: Queen Mary & Westfield College, London, England

In article <DaveZ-2304962024360001@msn_7_16.binc.net>
[e-mail] (David B. Zwiefelhofer) writes:

> My application is an appe (FBA) and I thought that the default stack size
> for an appe was 8K, but when I check it it is only 1960 bytes (1964 under
> 7.5.3) thus leading to my need to alter the stack size.

There's a tech note (I think it's PS02) which discusses these things.
The default stack size is 8k on old Macs, 24k on newer ones (by
"newer", I think I mean anything with colour QD!) and 2k for FBAs. It
can be increased, however: the tech note describes how to do it as well
as discussing a few other interesting things about FBAs.

Jeremy

---------------------------

>From [e-mail] (Nhan Tran)
Subject: Time running out in year 2040
Date: Sat, 4 May 1996 06:42:54 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

The GetDateTime() returns the number of elapsed seconds since 1904 (a 32-bit
value). On Feb. 6, 2040, it will wrap back to 0. What then? Probably at
that time, noone still use the good old Mac....

N.Tran


+++++++++++++++++++++++++++

>From [e-mail] (Rick Holzgrafe)
Date: Sat, 04 May 1996 13:21:11 -0700
Organization: Semicolon Software

In article <[e-mail]>, [e-mail] (Nhan Tran) wrote:

> The GetDateTime() returns the number of elapsed seconds since 1904 (a 32-bit
> value). On Feb. 6, 2040, it will wrap back to 0. What then? Probably at
> that time, noone still use the good old Mac....

Probably. That's nearly 45 years from now -- there have hardly *been*
computers for 45 years! :-)

But if you want to be optimistic, then I'd say that by then the MacOS will
have been through a lot of evolution, and will no longer be using a 32-bit
seconds counter for a clock.

Be glad you're on a Mac -- there are more than a few computer systems in
the world whose clocks are scheduled to break immediately after 11:59 pm,
December 31, 1999.

-- Rick Holzgrafe
   Semicolon Software
   [e-mail]
   http://www.opendoor.com/Rick/Semicolon.html

+++++++++++++++++++++++++++

>From Ben Trumbull <[e-mail]>
Date: Sat, 4 May 1996 19:30:12 -0400
Organization: Yale University

> In article <[e-mail]>, [e-mail] (Nhan Tran) wrote:
>
> > The GetDateTime() returns the number of elapsed seconds since 1904 (a 32-bit
> > value). On Feb. 6, 2040, it will wrap back to 0. What then? Probably at
> > that time, noone still use the good old Mac....

Mmmm.  Well a 64 bit value will only count a mere 600 billion years.  Of
course, I don't think the computers will continue to count after the sun
explodes ...

As if people can run system 6 software on a PPC, I don't think we have to
worry about this.

terminally curious,

Ben

______________________________________________________________________
Benjamin Trumbull
[e-mail]                  The optimist believes we live
Yale University                        in the best of all possible worlds,
http://www.cis.yale.edu/~casper        the pessimist fears this is so.




+++++++++++++++++++++++++++

>From [e-mail] (John W. Baxter)
Date: Sun, 05 May 1996 11:18:46 -0700
Organization: Internet for the Olympic Peninsula

In article <[e-mail]>, [e-mail] (Nhan Tran) wrote:

>The GetDateTime() returns the number of elapsed seconds since 1904 (a 32-bit
>value). On Feb. 6, 2040, it will wrap back to 0. What then? Probably at
>that time, noone still use the good old Mac....

That's why Apple, several years ago, created the 64-bit form of the time.
Zero is still at Jan 1, 1904; the time is a signed 64-bit number of
seconds from then, giving a range of about 33,000 years each way from that
point.  Clock chip still works as you describe.

Presumably, System Software (patches for old ROMs) and the ROM will adjust
before 2040 arrives, bringing with it The End of Time.

You may have noticed that the transition into the 2000s is pretty smooth,
in terms of converting dates like "2/15/09".  Apple arranged that for us
several years ago.  [If you really want "2/15/1909", you have to say so,
like that.]  Sometime around 2015**,  "2/15/96" becomes Feb 15, 2096 if
the algorithms in place stay the same and the long forms of date/time are
used by the program.  (**I found the changeover experimentally once, but
forget exactly when it is.)

   --John

--
  The primary cause of problems is solutions.
John W. Baxter    Port Ludlow, WA, USA     [e-mail]

---------------------------

>From [e-mail] (Joel Quejada)
Subject: To sync to VBL or not to sync....
Date: 2 May 1996 02:07:42 GMT
Organization: Texas Instruments, Inc.

I need to decide whether or not to sync to the VBL for each frame of my
animation, or just have a Time Manager task to maintain the frame rate
I want. There is a distinct improvement in smoothness when I sync to
the VBL interrupt, but I have read about people discouraging the use of
it.

What's the scoop?

Thanks,

Joel

+++++++++++++++++++++++++++

>From [e-mail] (Scott Squires)
Date: Thu, 02 May 1996 07:48:28 -0800
Organization: Puffin Designs

In article <4m95de$[e-mail]>,
[e-mail] (Joel Quejada) wrote:

>I need to decide whether or not to sync to the VBL for each frame of my
>animation, or just have a Time Manager task to maintain the frame rate
>I want. There is a distinct improvement in smoothness when I sync to
>the VBL interrupt, but I have read about people discouraging the use of
>it.
>

Usually the only real benefit to syncing to VBL is when a large
area of the image is moving across frame.  VBL will minimize the
tearing, but only if you have enough speed to blit in one video
frame.

-scott


Scott Squires               "Insert funny stuff here"
[e-mail]
[e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Michael Kelly)
Date: 2 May 1996 10:09:56 -0700
Organization: High Risk Ventures, Inc.

In article <ADAE194C966826A04@192.0.2.1>,
Scott Squires <[e-mail]> wrote:
>>I need to decide whether or not to sync to the VBL for each frame of my
>>animation, or just have a Time Manager task to maintain the frame rate
>
>Usually the only real benefit to syncing to VBL is when a large
>area of the image is moving across frame.  VBL will minimize the
>tearing, but only if you have enough speed to blit in one video
>frame.

And there's also the problem that different monitors have different
VBL frequencies, from about 67hz to 90hz or more.  If you use the
VBL to control your frame rate you'll end up with different frame
rates on different monitors.

--
| Michael A. Kelly                  High Risk Ventures, Inc |
| President                                    PO Box 70690 |
| [e-mail]                        Eugene, OR 97401 |
| http://www.hrvinc.com                      [phone] |

+++++++++++++++++++++++++++

>From Dave Howell <[e-mail]>
Date: Thu, 02 May 1996 15:55:51 -0700
Organization: Pablo Media

Michael Kelly wrote:
>
> In article <ADAE194C966826A04@192.0.2.1>,
> Scott Squires <[e-mail]> wrote:
> >>I need to decide whether or not to sync to the VBL for each frame of my
> >>animation, or just have a Time Manager task to maintain the frame rate
> >
> >Usually the only real benefit to syncing to VBL is when a large
> >area of the image is moving across frame.  VBL will minimize the
> >tearing, but only if you have enough speed to blit in one video
> >frame.
>
> And there's also the problem that different monitors have different
> VBL frequencies, from about 67hz to 90hz or more.  If you use the
> VBL to control your frame rate you'll end up with different frame
> rates on different monitors.

Well, whether or not you sync to the VBL, the screen refresh rate will be
different on different monitors, but your game's frame rate will be the same, so
that's not really an issue. Let's assume that the game rendering frame rate is
less than the screen refresh rate, and that the refresh rate is NOT an integral
multiple of the game frame rate. That's a pretty safe assumption. The trick then
is to avoid starting a CopyBits in the middle of a screen refresh, to eliminate
tearing.

QuickTime movie playback had this issue to deal with. Their solution was to
support "asynchronous codecs," which decompressed video frames (analogous to your
game's offscreen rendering or animation) and buffered them in non-interrupt time,
and then those buffered frames were blitted to the screen (using CopyBits or not,
depending on the codec) at the appropriate VBL time. That's why with recent
versions of QuickTime you don't get tearing in movie playback.

You can use QuickTime's approach to eliminate tearing by scheduling a VBL task
that does nothing but blit buffered frames to the screen. Note that as Scott
Squires said, it's really not an issue unless your whole screen tends to change
at once, as in a first-person game like Marathon or Doom. In a game with a static
background and small animating sprites, it's not so critical.

Dave
 ____________________ ___     _   _      ____________________
|                    | _ \___| |_| | ___|                    |
|    Dave Howell     |  _/ _ | _ \ |/ _ \     Pablo Media    |
|____________________|_| \___|___/_|\___/____________________|

+++++++++++++++++++++++++++

>From [e-mail] (Joel Quejada)
Date: 3 May 1996 13:37:00 GMT
Organization: Texas Instruments, Inc.

Scott Squires ([e-mail]) wrote:
:
: Usually the only real benefit to syncing to VBL is when a large
: area of the image is moving across frame.  VBL will minimize the
: tearing, but only if you have enough speed to blit in one video
: frame.
:
: -scott


That's what I thought....I have between 1-5 sprites moving on screen at
any given time. Each sprite is about 50x80 pixels in size. Without
syncing to VBL (only using a Time Manager task to control the frame rate)
I get OK smoothness, but when syncing to VBL it is smooth as glass. Could
I be doing something wrong? Could the fact that all of the sprites are
moving from top to bottom (or bottom to top) be causing it to be more
sensitive to the VBL?

I just hear so many people say that syncing to VBL is not necessary,
even some that discourage its use, but I just don't think the smoothness
is acceptable unless I sync to VBL.

Thanks!

Joel

+++++++++++++++++++++++++++

>From [e-mail] (Michael Kelly)
Date: 3 May 1996 09:06:41 -0700
Organization: High Risk Ventures, Inc.

In article <[e-mail]>,
Dave Howell  <[e-mail]> wrote:
>Michael Kelly wrote:
>> And there's also the problem that different monitors have different
>> VBL frequencies, from about 67hz to 90hz or more.  If you use the
>> VBL to control your frame rate you'll end up with different frame
>> rates on different monitors.
>
>Well, whether or not you sync to the VBL, the screen refresh rate will be
>different on different monitors, but your game's frame rate will be the same, so
>that's not really an issue.

You misunderstood me.  I was saying that if you use the VBL to
control your game frame rate you'll end up with a different game
frame rate with different monitors.  You should use some other
method of keeping time to control your game frame rate.  I have
used both TickCount and the Time Manager in the past.

--
| Michael A. Kelly                  High Risk Ventures, Inc |
| President                                    PO Box 70690 |
| [e-mail]                        Eugene, OR 97401 |
| http://www.hrvinc.com                      [phone] |

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Fri,  3 May 1996 12:14:37 -0400
Organization: Carnegie Mellon, Pittsburgh, PA

[e-mail] (Joel Quejada) writes:
> That's what I thought....I have between 1-5 sprites moving on screen at
> any given time. Each sprite is about 50x80 pixels in size. Without
> syncing to VBL (only using a Time Manager task to control the frame rate)
> I get OK smoothness, but when syncing to VBL it is smooth as glass. Could
> I be doing something wrong? Could the fact that all of the sprites are
> moving from top to bottom (or bottom to top) be causing it to be more
> sensitive to the VBL?
>
> I just hear so many people say that syncing to VBL is not necessary,
> even some that discourage its use, but I just don't think the smoothness
> is acceptable unless I sync to VBL.

Generic answer to low-level hackery debates: make it optional. Stick a
checkbox in the preferences dialog:
[] Fast, not quite so smooth
[] Smooth, not quite so fast

It's also much nicer to get email saying "Smooth mode doesn't work"
than it is to get email saying "Your damn game doesn't run!"

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From [e-mail] (Michael Kelly)
Date: 3 May 1996 09:18:03 -0700
Organization: High Risk Ventures, Inc.

In article <4md25s$[e-mail]>, Joel Quejada <[e-mail]> wrote:
>I just hear so many people say that syncing to VBL is not necessary,
>even some that discourage its use, but I just don't think the smoothness
>is acceptable unless I sync to VBL.

It depends on your program.  If you're syncing to VBL, and your screen update
is slow enough so that the beam catches up with your drawing, you'll still
get tearing.  If your screen update is of a very consistent speed, the tearing
will be very noticeable because it will always happen around the same place.

I had this problem with Cyclone on slower machines, so I stopped syncing to
the VBL.  I get tearing of course (it's unavoidable if you're not syncing to
VBL), but it happens in a different place every frame, which for Cyclone,
since it's a sprite-on-background space game, makes it nearly undetectable.

If you run your game on a slower machine, you may discover that you get some
nasty tearing when syncing to the VBL.

--
| Michael A. Kelly                  High Risk Ventures, Inc |
| President                                    PO Box 70690 |
| [e-mail]                        Eugene, OR 97401 |
| http://www.hrvinc.com                      [phone] |

+++++++++++++++++++++++++++

>From [e-mail] (Christopher L Tate)
Date: Fri, 3 May 1996 18:25:16 GMT
Organization: The World Public Access UNIX, Brookline, MA

Michael Kelly ([e-mail]) wrote:
: In article <4md25s$[e-mail]>, Joel Quejada <[e-mail]> wrote:
: >I just hear so many people say that syncing to VBL is not necessary,
: >even some that discourage its use, but I just don't think the smoothness
: >is acceptable unless I sync to VBL.

: It depends on your program.  If you're syncing to VBL, and your screen update
: is slow enough so that the beam catches up with your drawing, you'll still
: get tearing.  If your screen update is of a very consistent speed, the tearing
: will be very noticeable because it will always happen around the same place.

: If you run your game on a slower machine, you may discover that you get some
: nasty tearing when syncing to the VBL.

And syncing to VBL can hurt your animation performance.

Bear in mind that syncing to the VBL means *delaying* drawing until the
interrupt pings.  Unless you're prepared to take advantage of the time
between when your program is read to update the scren and the time the VBL
interrupt hits, that's just wasted time, and will slow your program down.

If you're double-buffering, or using some other scheme to queue drawing
while you continue with calculations, then you don't really have to worry
about the delay, and syncing to VBL won't hurt as much.

--
Christopher Tate <*> [e-mail] <*> http://world.std.com/~ctate/
                  "What's in the briefcase?"   "Kosh."

+++++++++++++++++++++++++++

>From Dave Howell <[e-mail]>
Date: Fri, 03 May 1996 13:27:05 -0700
Organization: Pablo Media

Christopher L Tate wrote:
>
> Michael Kelly ([e-mail]) wrote:
> : In article <4md25s$[e-mail]>, Joel Quejada
> : <[e-mail]> wrote:
> : >I just hear so many people say that syncing to VBL is not
> : >necessary,
> : >even some that discourage its use, but I just don't think the
> : >smoothness
> : >is acceptable unless I sync to VBL.
>
> : It depends on your program.  If you're syncing to VBL, and your
> : screen update
> : is slow enough so that the beam catches up with your drawing, you'll
> : still
> : get tearing.  If your screen update is of a very consistent speed,
> : the tearing
> : will be very noticeable because it will always happen around the
> : same place.
>
> : If you run your game on a slower machine, you may discover that you
> : get some
> : nasty tearing when syncing to the VBL.
>
> And syncing to VBL can hurt your animation performance.
>
> Bear in mind that syncing to the VBL means *delaying* drawing until
> the
> interrupt pings.  Unless you're prepared to take advantage of the time
> between when your program is read to update the scren and the time
> the VBL
> interrupt hits, that's just wasted time, and will slow your program
> down.
>
> If you're double-buffering, or using some other scheme to queue
> drawing
> while you continue with calculations, then you don't really have to
> worry
> about the delay, and syncing to VBL won't hurt as much.
>

Christopher,

That's right. If the nature of your game requires synchronizing your
screen updates to vertical blanking to avoid tearing, then you have to
do it right. You have to buffer rendered frames in offscreen GWorlds.
Then your CopyBits (or custom blit) to the screen should take place at
interrupt time. This is the approach taken by asynchonous QuickTime
codecs, and it works very well but it's not necessarily EASY to
implement. It would be a SWEET feature to add to DrawSprockets though,
wouldn't it (if it's not in there already)? Anyway, the point is that
syncing CORRECTLY to VBL will not hurt your performance. You never want
to just WAIT until the next VBL unless your game does not require speed
(like Scrabble or Chess).

One other game development tip that can be gleaned from looking at
QuickTime is that a rock-solid frame rate creates much smoother
animation than a faster--but not steady--frame rate. In other words, if
your game gets a frame rate that varies between 15-18 fps on a given
target machine, you should just make it do 15 fps, and it will actually
look faster and smoother. To take advantage of this, you need to measure
performance at runtime and adapt the frame rate during gameplay.

Dave
 ____________________ ___     _   _      ____________________
|                    | _ \___| |_| | ___|                    |
|    Dave Howell     |  _/ _ | _ \ |/ _ \     Pablo Media    |
|____________________|_| \___|___/_|\___/____________________|

---------------------------

>From "Christophe ANDRES" <[e-mail]>
Subject: [Q] Clean way to know when a serial port is "stolen"
Date: 27 Apr 96 16:20:36 +0100
Organization: CalvaCom Networks

    I am looking for a clean method to know when a serial port is "stolen"
from under me.

To clarify a bit. I have a nice little program (part of a bigger project)
lurking in the background with a serial port open, gently waiting for a
modem to tell it something.
Then come a big evil program who grabs the serial port (closing in by brute
force and reopen it for its own purposes), uses it and then ultimately
closes it and quits (lets say a PPP module).

The result of this scenario is that the background program is stuck, with
an invalid reference number to the serial port.

I can think of several "not so" clean methods to be notified of "brute
force" claiming of a serial port (or any driver), but is there a clean one
?

Yes I know I am followin th lofty quest for serial port arbitration ;)

Any help would be welcome.


=======================================================
   Christophe ANDRES                                   Chrisoft
20, rue Prosper Merimee                      (Software development)
67100 STRASBOURG. FRANCE
Tel.: [phone]                            Fax: [phone]
Internet : [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (David Phillip Oster)
Date: Sun, 28 Apr 1996 08:39:58 GMT
Organization: IOpener

In article <ADA7F9D8-14492@194.51.119.116>, "Christophe ANDRES"
<[e-mail]> wrote:

>         I am looking for a clean method to know when a serial port is "stolen"
> from under me.

1.) You can patch the _Open system call (Trap A000) to see if your serial
port is being opened by someone else. If you patch is in the system heap,
you'll get called by other programs using open.

2.) there is a bit in the flags word in the front of the driver, that
says whether that driver is open or not.


My advice: if the serial port is closed, open it , use it for a short time,
and close it. If it is open, try again later.
- ------- [e-mail] ----------
"A man hears what he wants to hear and misremembers the rest."
     -- Paul Simon, ("The Boxer")

+++++++++++++++++++++++++++

>From [e-mail] (Christopher Swan)
Date: Tue, 30 Apr 1996 07:40:07 +1200
Organization: Raine Storm Softworks

>I can think of several "not so" clean methods to be notified of "brute
>force" claiming of a serial port (or any driver), but is there a clean one
>?

The easiest way is to use the ref num and look for a 'driver not open'
error. Unfourtunately, you can't tell when you're both reading from it.

--

Cheers, Chris

- ---------------------------------------------------------------------
Christopher Swan                                 CompuServe 100354,3427
PO Box 11567, Wellington, New Zealand                 or [e-mail]
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From "Christophe ANDRES" <[e-mail]>
Date: 30 Apr 96 14:10:56 +0100
Organization: CalvaCom Networks


>1.) You can patch the _Open system call (Trap A000) to see if your serial
>port is being opened by someone else. If you patch is in the system heap,
>you'll get called by other programs using open.
>

That is the method I spoke of, being "not so" clean. I would have prefered
avoiding any patch :(



=======================================================
   Christophe ANDRES                                   Chrisoft
20, rue Prosper Merimee                      (Software development)
67100 STRASBOURG. FRANCE
Tel.: [phone]                            Fax: [phone]
Internet : [e-mail]


---------------------------

End of C.S.M.P. Digest
**********************